A recharge/refill of an account with a telecommunications operator is performed by a mobile user in order to keep the balance (amount or units for example Euro, seconds, bytes or the like) at a suitable level for allowing day to day activities such as calling/texting/browsing etc. A suitable balance has to be maintained in a prepaid subscription. A mobile user uses a voucher which can be described as an entity which is in a physical form, for example a printed coupon, paper containing a secret code, or non-physical form, for instance an encrypted secret code sent in an email/online etc.
The Interface between the OCS (Online Charging System) and the external recharge server is shown in FIG. 1 as in accordance with the Third Generation Partnership Project (3GPP) Technical Specification (TS) 32.296. The OCS interacts with the operator support network, or a hosted network e.g. a retail shop, (right hand side in the figure) as well as with different parts of a radio communication network, including core network(s) (CN) and Radio Access Network(s) (RAN) on the left hand side in the figure. Abbreviations used are in accordance with standards: PCRF (Policy and Charging Rules Function), MSC (Mobile Switching Center), SGSN (Serving GPRS Support Node), PGW (PDN Gateway), WLAN (Wireless Local Area Network), IMS (IP Multimedia Subsystem), CSCF (Call Session Control Function), AS (Application Server), MRFC (Media Resource Function Controller), MMS (Multimedia Messaging Service), GMLC (Gateway Mobile Location Centre), MBMS (Multimedia Broadcast Multicast Service), PoC (Push-to-Talk over Cellular, SMS (Short Message Service). Between the OCS and the recharging server there is an interface Rr as an online reference point.
FIG. 2 illustrates the refill sequence of a prepaid account, where MS is a mobile station, ABMF is here the account balance management function and the VDB is a voucher database (DB).
The steps involved in the refill process are explained below.
1. A mobile station (used by a mobile user) initiates a refill request.
2. The refill request reaches a recharge server which validates the same with the VDB and determines the balance which should be added, after applying any discounts/promotions. The validation process involves the recharge server contacting the VDB for availability, authenticity, and authorization of the voucher.3. After validation, the recharge server contacts the ABMF to update the balance of the mobile user account.4. The ABMF updates the balance of the prepaid account of the mobile user in the balance database.
In the above process there are cases where the update transactions are lost due to e.g. network issues either during the update of the balance or during the update of the voucher. Due to this, the user balance is not updated or the voucher state is incorrect i.e. voucher state may be set to used while still the user balance is not updated, or set to unused even if the user balance has been updated. This may lead to in-consistent revenue management due to non-fulfilment of refill transactions, and customer churn due to poor user experience, since it would require more time & effort by means of customer care support and multi-level approval processes involved in clearing a voucher for manual rectification.
FIG. 3 is a signalling diagram illustrating how communications can get lost which would require manual assistance to get the update of balance and/or voucher state correct (vid is the voucher identifier (ID), and amt is the amount with which the account should be updated). If any of the messages 4-7 get lost or are otherwise corrupt or not received correctly, the recharge server will not know whether the account was updated or not. In that case, the voucher may not be set to neither used nor unused state, but rather as pending. This needs then be sorted out manually, as illustrated in FIG. 4.
In a normal case, a voucher transition from Unused state to Locked state (1. Reserve) during a Refill transaction, and from a Locked state it moves to Used state (3. RefillDone-System) if the Refill is successful or reverts back to Unused state (3′. RefillNotDone-System) if the Refill is unsuccessful. In case of no acknowledgement due to a communication failure or programmatic error after a certain time period, then the voucher state is moved to Pending state (2. Timeout). Vouchers with Used state are Archived (4. Archive). Refill(Not)Done-System means refill is handled by the Recharge Server. Refill(Not)Done-Manual means refill is handled by manual intervention.